Macros

All of the processing logic for ProActiveX is contained in Excel macros. In most cases each macro is in a separate module. The controlling modules are named Get_ALL_Model_Data and Pop_ALL_Model_Data. There are also macros in some of the Excel Sheet Objects. For example, Sheet04 (Resources) has subroutines that dynamically fill in the Path Network drop-down list (using the information on the Path Networks sheet) every time the Resources sheet is activated. This is one method for keeping the drop-down list in sync whenever you update the data.

When the user clicks on the Build All button on the Controls Sheet, the create_model subroutine is started (found in the POP__ALL_Model_Data module). This subroutine then calls subroutines in other modules to process each type of data. The order in which the subroutines are called is important, since many of the modules in ProModel depend on information in other modules. For example, the Locations module must be built before the Path Networks module, because the Path Networks module references Locations.

All of the subroutines in ProActiveX use the constants established in the PM_CONSTANTS module. You will also find this module recorded in the file called PM_CONSTANTS.bas. The main purpose of the constants is to provide a method for accessing the parameters to the ProModel properties and methods data, without having to remember the numbers associated with each table and field.

There are some other useful subroutines that are used throughout the program to do things like showing the right error message or replacing Excel style carriage returns with ProModel style carriage returns.

In many cases when you look at the tables in ProModel, what you actually see on the screen is a main table and one or more sub tables.

The subroutines in ProActiveX must process the data for all tables simultaneously by using For...Next or Do While... loops.

In many of the data tables, the first field is a Name or ID field that identifies each record in the table and does not allow duplicates. In the subroutines that populate these types of tables, the logic is designed to search for an existing ProModel record with the same name or ID. If a record is found, all of its fields will be updated. If no record is found, a new one will be appended. In tables that have no identifying field, records are always appended.